Calling OpenTransport from a code resource can be tricky. This package demonstrates how to do it using both Metrowerks C and Symantec C for MPW. The package contains the files necessary to build a HyperCard XCMD that displays the default Ethernet address for the machine using OpenTransport native calls.
The Package
The package includes the following files:
• Read Me — This file.
• OTGetDefaultEthernetAddress(MW) — Folder containing the Metrowerks C sample.
•• OTGetDefaultEthernetAddress.c — C source code for the XCMD.
•• OTGetDefaultEthernetAddr — A HyperCard stack to test the XCMD.
• OTGetDefaultEthernetAddress(SC) — Folder containing the Symantec C sample.
•• Worksheet — Instructions for building the XCMD.
•• OTGetDefaultEthernetAddress.c — C source code for the XCMD.
•• OTGetDefaultEthernetAddress — Another HyperCard stack to test the XCMD.
I compiled and tested this stuff on an 840av and 6100av running OT 1.1b11.
Issues
There are a number of issues related to calling OT from a code resource. The first is just getting the code resource to link. This is surprisingly tricky because the OT libraries contain global data with initialisers that causes problems for a number of development environments when they’re creating a code resource.
The second problem is creating an A5 world. OT requires that each client (ie program calling it) create its own A5 world and have OT globals allocated in that A5 world. This is real easy if you’re an application but a total pain for a code resource.
Metrowerks Code
Requirements
To use this code you will need:
1. HyperCard or HyperCard Player — Any version should do.
2. Metrowerks CodeWarrior 8 — It may work with earlier or later versions but I haven’t tried.
3. OpenTransport 1.1 SDK — At the time I wrote this OT was not final so I can’t give you any recommendations for how to find this although the plan was for it to be on the MacOS SDK CD series.
Special Considerations
CodeWarrior uses an A4 world to access its global variables inside a code resource. The OpenTransport 68K libraries are all A5 relative, which might seem like a problem. This code demonstrates a workaround for that problem.
The A5 relative bits of the OT libraries include boil down to code and data references. The code references are of the form…
JSR $xxxx(A5)
The CodeWarrior .o file conversion process converts these to…
JSR $xxxx(A4)
… which the CodeWarrior linker converts to PC relative addresses, ie…
JSR $xxxx(PC)
The other problem is the data references. These are of the form…
LEA $xxxx(A5),A0
MOVE.L $xxxx(A5),D0
...
… and so on. The CodeWarrior .o file conversion process leaves these files unchanged but the linker changes the offsets (ie $xxxx in the listings above) to the correct offsets from A4 to the relevant data sections. This means that all you need to do is keep A5 pointing to the same location as A4 and everything will be fine.
Coding Considerations
This introduces a number of complication to your code. When you enter the code resource you must preserve the value of A5 (using the GetCurrentGlobalWorld inlines) , initialise the CodeWarrior globals (by calling the CodeWarrior SetCurrentA4 routine) and then set the value of A5 to the value of A4 using SynchGlobalWorldFromA4 .
On exit you must undo the damage, restoring A5 to the original value (using SetCurrentGlobalWorld) as well as calling CodeWarrior’s SetA4 routine to restore A4 to its original value.
The sample code demonstrates this process.
The only other problem you might encounter is inside OT notification routines. When OT calls your notifier it automagically sets A5 to the value it had when you called OTInstallNotifier. You must also set the A4 register to that value so that CodeWarrior code can access its globals. You can do this using the CodeWarrior SetupA4.h library or by calling SynchA4FromGlobalWorld. Don’t forget to preserve the old value of A4 lest you upset OT.
Project Considerations
The project has the following CodeWarrior attributes:
• It links with the near libraries not the far libraries (eg OpenTransport.n.o and OpenTransportExtn.n.o). I’m not sure of the consequences of linking with the far libraries.
• It has 4 byte integers set, always a good idea IMHO.
• It links with Model Near “ANSI (4i) C.A4.68K.Lib” and “MathLib68K (4i).A4.Lib” because we want 4 byte integers and A4 relative globals.
• I set the following non-default options: Small Code Model in the 68K Processor panel, Link Single Segment in the 68K Linker panel, and Code Resource and Extended Resource in the 68K Project panel. Some of these are not required but I got a working system and I didn’t want to mess with it. The key option is definitely the Extended Resource option.
Symantec Code
Requirements
To use this code you will need:
1. HyperCard or HyperCard Player — Any version should do.
2. MPW Pro/ETO 19 — It may work with earlier or later versions but I haven’t tried.
3. OpenTransport 1.1 SDK — At the time I wrote this OT was not final so I can’t give you any recommendations for how to find this although the plan was for it to be on the MacOS SDK CD series.
4. ASLM 2.0 SDK — This is available on the MacOS SDK CDs and MPW Pro/ETO.
Coding Considerations
There is a classic Macintosh Technote called “PT 35 Stand Alone Code, ad nauseam” <http://dev.info.apple.com/technotes/Archive/Platforms_&_Tools/pt_35.html> which describes the mechanism for getting your own global (ie A5) world from stand alone code. This is recommended reading for anyone who wants to mess around with 68K standalone code.
Fortunately however much of the technology in this technote is embodied in the ASLM utility routines provided in LibraryManagerUtilities.[ph]. So rather than reinvent the wheel I simply call these routines (GetCurrentGlobalWorld, InitCodeResource, SetCurrentGlobalWorld and FreeGlobalWorld) to create, use and tear down a global world. This makes the task surprisingly easy.
Linking Requirements
That is not to say that working out this stuff was easy. Specifically you have to be very exact about the options you pass to the MPW Link tool to create your code resource. If you encounter strange linking problems, check your options against mine. My biggest problems were:
1. Forgetting to specify -t XXXX -c XXXX, which caused the tool to think it was creating an application (even though I had passed the -rt option!) which caused very bizarre linking errors.
2. Forgetting to specify a main entry point (ie -m MAIN) which caused very strange linking problems.
I’m sure an MPW guru could explain this [Hey, I thought I was an MPW guru!] but for most people these points are just something to avoid.
Other Compilers
I have only done a little bit of investigating of how to OT from a code resource with other compilers. I don’t think it’s possible to do it from the Think Project Manager because of a problem with it’s .o file importing tool. Doing it from PowerPC environments is most probably a lot easier because the PPC has a single runtime architecture shared by all compilers. But beyond that I’m in the dark. I hope that this package will cover most people’s requirements.
Credits and Version History
If you find any problems with this stuff, mail <DevSupport@applelink.apple.com> with “Attn: Quinn” as the first line of your mail and I’ll try to fix them up.
Version 1.0b2 is the first widely distributed version.
